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(54) Abstract Title 

Method of exchanging address information using auto-negotiation to assist network topology 

(57) In the auto-negotiation process between two network devices according to the IEEE 802.3 standard, the 
'Next Page* function, which permits additional information to be exchanged during the link-up process, is used 
to exchange address information. MAC or IP addresses and a code specifying the nature of the address 
information are transmitted in the Next Paige message code fields. The address information may be retrieved 
from memory and stored in registers under the control of a state machine which performs the 
auto-negotiation. The address information is used to deduce network topology without the use of a complex 
deduction algorithm. 
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METHOD OF EXCHANGING ADDRESS INFORMATION USING AUTO- 
N'EGOTIATION TO ASSIST NETWORK TOPOLOGY 

Field of the Invention . 

This invention generally relates to the design and/or management of packet-based 
communication networks and more particularly to the process of discovery of a network's 
topology. It specifically concerns the development of a technique known as auto- 
negotiation to enable the exchange of address information and thereby to facilitate the 
process of discovery. 

Background to the Invention 

Having the ability to represent a computer network makes debugging a network 
significantly easier. A network administrator would be able to see the network topology 
and can use that knowledge to aid in performance diagnostics or a re-design of the said 
network. Knowing the network topology also maikes life easier for the network 
administrator to configure the network, because the adminstrator can traverse the network 
devices (using say Tielnet* or web browsers) and can make configuration changes and 
know what devices those changes may or may not effect. 

The present invention is intended to facilitate the process of topology discovery, and 
particularly to facilitate the exchange of address information (such as network addresses 
and/or media access control addresses). It also has the major advantage that the IP or 
MAC address information is exchanged before a link between devices is fully established 
for the passage of data packets, so that valuable network time or bandwidth is not 
unnecessarily occupied 

During the development of the 100BASE-T standard (802. 3u) Auto-Negotiation, the 
technique of passing configuration information from one device to another as part of the 
link start-up sequence was defined. This technique provides a means whereby devices at 
the ends of a 'twisted-pair' link could exchange their abilities and then start-iip running at 



their highest common operating ability. As part of this auto-negotiation function the 
additional, optional, 'Next Page' function was defined (see IEEE Standard 802.3, 1998, 
Clause 28.2.3.4). The 'Next Page' function allows the transfer of arbitrary data between 
two devices on a link after the basic configuration information has been exchanged but 
prior to the link going into operation (i.e. the normal transmission of addressed data 
packets). Subsequently, during the development of the Gigabit Ethernet Standard 
(802.32), the Auto-Negotiation function was extended to operate over IGb/s fibre links. 

The invention is based on the fact that this Next Page transfer can only occur on the point 
to point link between two PHYs (physical layer devices), and the realisation that this fact 
enables the unique identification of the device at a far end of the link. Thus the *Next 
Page' functional tool forms the basis of a faster and more reliable topology discovery 
method. 

There are (as described in the Standard) two types of Auto-Negotiation Next. Page 
encoding. "Message" Pages and "Unformatted" or ''User" Pages. A Next Page message 
exchange consists of the exchange of a Message page and a number of User/Unformatted 
pages. The . Message page defines the type of Next Page exchange taking place by the 
message code it contains. The number of User/Unformatted pages that follow is 
determined by the particular Next Page message code. 

There are at least two approaches that can be used to provide the transfer of IP and/or 
MAC addressees between the two PHYs at the end of a link. The first is to use the ability 
to transfer proprietary user defined information as part of the already defined Message 
code #5 . Organisationally Unique Identifier (OUI) tag code. Next Page exchange (see 
IEEE 802.3-1998 Clause 28C.6). Another approach is to define new Next Page tag codes 
that provide for exchange of MAC/IP addresses directly. The second approach would.be 
preferable, because since it could provide a multi-vendor interoperable system that uses 
fewer Next Pages exchanges than the OUI tag code approach. However currently it would 
have the disadvantage that it would require allocation of codes by the authority (IEEE) 
controlling the Standard. 



Figure 1 illustrates a simple packet-based communication network. 

Figure 2 illustrates the network as it is interpreted by a network management station. 

Figure 3 illustrates the network as it may be interpreted employing the invention. 

Figures 4 to 10 illustrate various forms of 'Next Page' messages which can be used to 
perform the invention. 

Figure 11 illustrates scheniatic the relevant parts of a device which incorporates the 
invention. 

Description of a Preferred Example 

Figure 1 shows a simple network wherein an NMS (network management station) 1 is 
connected to a managed switch 2 connected by one port to a managed repeated 3 itself 
connected to 'users* (personal computers) 4 and 5. By another port the managed switch 2 
is connected to an unmanaged repeater 6 itself connected to a PC 7 and a printer 8. 

The responsibility of the NMS is to monitor and control agents. An agent is a softv/are 
component residing in a network device e.g. a switch or a repeater. Devices that can run 
agent software are known as 'managed'. Conversely, unmanaged devices do not run any 
agent software and are not at present visible to the NMS. 

By reading the source media access control address (MAC) addresses of incoming 
packets, a managed device can learn which MAC addresses are related to a particular port. 
In Figure 1, the left-hand port 10 of the managed switch 2 will have three MAC addresses 
associated with it: the managed repeater 3 and its two PCs 4 and 5. The port/MAC data are 
in accordance with well-known praaice stored in agent look-up tables. 




By reading the pon/MAC look-up tables in each managed device, the NMS attempts to 
deduce the topology of the network. Figure 2 below shows the network topology from the 
point of view of the NMS. 

Since the unmanaged repeater 6 does not have its own MAC device it is invisible to the 
NTMS. and only the end MAC devices (the PC and the printer) can be detected by the 
NMS As far as the NMS is concerned, the right hand connection to the managed switch 2 
looks like a wire segment 11. 

Since a topology discovery algorithm is carried out by the NMS 1, only it has a view of 
the network Although the agents in the network appliances store port/MAC tables, they 
cannot use this information to deduce their local connectivity. Thus in Figure 2, the 
managed switch 2 is not aware of the managed repeater 3: 

As agents are not aware of their local environment, a fairly complex deduction algorithm 
is needed by the NMS to discover the overall topology. 

Devices learn MAC addresses, e.g. by storing in a forwarding database the source address 
(SA) of an incoming packet and the allotted number of the port by which the packet was 
received. However, MAC addresses learnt in this manner can be unreliable. When for 
example a PC or a printer is diisconnected, it takes time for the agent to realise that its 
port/MAC tables are no longer valid. Moreover, some older types of device do not erase 
old MAC addresses that they have learnt. This makes it difficult for the NMS to track the 
movement of, for example, PC's from one port of the network to another. 

Furthermore a discovery process generates a large amount of network traffic and therefore 
may consume excessive time or bandwidth. 

When two devices (e.g. a PC and a repeater) first attempt to connect to each other, their 
physical layer components (PHYs) use a process called 'auto-negotiation'. This is fully 
described in IEEE Standard 802.3, 1998 Edition, published by the Institute of Electrical 

and Electronics Engineers, Inc., New York, USA (ISBN 0.-7381.0330-6), pages 689 to 



734. The main purpose of auto-negotiation is to reconcile the wire data speed between the 
two devices. Auto-negotiation also has a feature called 'Next Page' that permits additional 
data to be exchanged during the linking-up process. If present, this extra data is stored in 
certain PHY registers (as described in the Standard) and can be made available to an 
agent. 

The present invention specifically concerns on using the Next Page ilinction to exchange a 
unique port identification (ID) that fully and reliably identifies a device and its location. 
The port ID preferably comprises an address, i.e. a MAC or IP address, a *Unit number', 
which may be useful for locating a unit in a large stack in a wiring closet, and a ^hardware 
port number', which may be useful for identifying a cable connection on a unit. 

The agent in a device can store this information for each attached device in a look-up 
table. Since the address information is directly associated with the PHY connection at 
each end of the cable, topology deduction is not required, and the agent is now aware of its 
nearest neighbours. It is now much easier for the NMS to record the exact network 
topology and to track PCs etc which are moving in the network. The Mearning' problem 
disappears. 

In the event that the nearest neighbour of a managed device is an unmanaged device, the 
nearest neighbour's *Next Page' will be empty. The PHY in the managed appliance will 
register this fact, and therefore the agent in the managed device will still know that there is 
a unit connected between it and funher downstream devices. Thus as shown in Figure 3 
the software agent in the managed switch 2 will now be aware of the existence of an 
unknown unit (actually the unmanaged repeater) 6 between the switch 2 and the devices 7 
and 8. 

Since the information exchange is carried out during the physical layer link-up process 
(i.e. not using LAN data packets) valuable network bandwidth is not wasted. 

There is an option whether to exchange MAC addresses or protocol (network) addresses 
(IP addresses) using the Next Page feature. 




Whereas MAC addresses are more 'reliable' because not all end devices have. IP stacks 
(e.j£. printers), and it takes time for PCs to render their IP stacks fully operational, one 
cannot use Web agents to ^hot-link' from device to device using a web browser in the 
NMS Users would need to use RARP (reverse address resolution protocol) to obtain IP 
addresses. 

Using a Web browser one can hot-link from device to device (with embedded Web 
agents), but that requires IP addresses which are not necessarily always possessed by some 
devices. 

As can be seen above the exchange of either a IP or MAC address through Next Page 
exchange can be used for topology determination. The following describes preferred 
mechanisms to exchange either of these types of addresses. If desired only one of the 
several possible types of exchange need to be implemented. 

The 48-Bit Universal LAN MAC Address, used in Ethernet as the Ethernet MAC 
Address, consist of two pans (see IEEE802-1990 subclause 5.2). The first 24 bits 
correspond to the Organisationally Unique Identifier (OUI) as assigned by the IEEE. The 
second part, comprising the remaining 24, is administered locally by the assignee. When a 
device is manufactured the OUI is combined with a 24 bit, locally administiered value 
which is registered as used so it can never be used again. In this way a unique 48 bit MAC 
address is formed. As can be seen however once 2^24 (nearly 17 million) similar units are 
manufactured the assignee has to return to the IEEE and request a new OUI. 

The OUI Tagged Next Page exchange allows the transfer of an OUI, and related user- 
defined user codes, from a far end device. The transfer of these user-defined user codes 
within the OUI Tagged Next Page exchange can be used to convey the actual MAC or IP 
Address information between the two PHYs on the point to point link. As the user-defined 
user codes are related to the OUI that is, only if the OUI is known to the receiving device, 
can the user-defined codes transferred be interpreted, this mechanism is not a multi-vendor 
approach. If for example another vendor's equipment were to receive an OUI Tagged 



Next Page message from a particular vendor, even if it was able to recognise the OUl as 
belonging to that particular vendor, it would be unable to decode it, because format is 
defined by that particular vendor 

A related issue is the OUI to use. If the OUI of the equipment in which the PHY is 
installed were used this would present a challenge whenever a new OUI had to be 
obiained from the IEEE as described above. As there is no way of predicting what this 
new OUI may be this would mean that equipment manufactured prior to the new OUI 
bemu allocated would be unable to recognise the new OUI and this mechanism would fail. 
There is however no requirement that the OUI sent in the OUI Next Page message 
exchange be the same as the OUI of the equipment that the PHY is installed in, only that it 
is an OUI owned by the manufacturer of the equipment. The OUI therefore used in the 
OUI Tagged Next Page exchange is an OUI that is already in use, and will never be 
changed once allocated. This does present an interesting feature for MAC address 
transfers as it therefore requires that two OUIs are transferred, the OUI Next. Page 
exchange OUI and the OUI of the equipment. This means that a full 48 bit Ethernet MAC 
address has to be transferred as well as the OUI in each of the OUI Next Page messages. 

There is an optimisation when the OUI of the OUI Tagged Next Page message matches 
the OUT of the equipment sending the massage allowing only 24 bits to be sent but that 
optimisation is not examined in detail here. 

Each message code field employed in the current Standard (see pages 699-702 thereof) is 
a two-byte message including an 11-bit field and a 5-bit ^header*. Each exchange 
according to the invention comprises a first field (identified as the * message code' in each 
of the remaining figures followed by four subsequent fields, the first to fourth 'user 
codes'. The message field indicates by its coding (bits 0 and 2) that the following fields 
are an exchange of information according to the invention and the user codes are as 
described in the following. The 'header' of each field has five bits (NP, Ack, MP, Ack2 
and T) which have the significance prescribed in the Standard. NP indicates whether the 
Next Page is the last page (0) or not (1). Ack when set to indicates that the device has 
successfully received its link partner's link code word (see Clause 28.2.1.2.4 of the 




Standard). Ack2 when set to indicates an ability to comply with a Next Page message. 
MP denotes a Message Page ( 1 ) or an unformatted page (0). Toggle (T) is a bit that should 
take the opposite value of a toggle bit in a previously exchange Link Code Word. 

Currently, the Standard prescribes two kinds of * message code pages', each of which 
consists of a message code and four user codes. The two types are a 'remote fault' page 
and an OUI Tagged Next Page. The form of the invention shown in Figures 4 to 7 uses an 
QUI Tagged Next Page. 

In Figure 4, bits O23-O0 constitute the organisationally unique identifier (OUI). Bits U19-U0 
are the specific user defined code value. In Figure 5, the bits 3Com OUI23-0 are an 
assigned 24-bit OUI. Bits OP.voare operation code and Dis^iare a 16-bit user defined code 
value. In Figure 6, OPCODE.v() is an operation code and IP32.0 is a 32-bit IP address. In 
Figures 7a to 7c, MAC47^) is a 48-bit MAC address. In Figure 9, lai-ois a 32-bit Internet 
Protocol Address. R represents a bit reserved for future use; it will be set to '0' and 
ignored on receive. In Figure 10, Ai7.o is a 48-bit MAC address. Mio-o indicates a message 
code (which would require an actual value to be allocated by the authority controlling the 
Standard). 

As will be apparent firom, for example. Figure 4, after the inclusion of the OUI bits, O23 - 
Oo, only twenty bits (U19-U1) remain, so that the maximum 'payload' is only twenty bits 
per Next Page. It is preferable to allot some of these bits to an operation code (e.g. bits 
OP3 to OP I in Figure 5) which can among other things define the nature of the code bits 
thai follow; it may denote whether the bits are part of an IP address, as in Figure 6 or a 
MAC address as in Figures 7a-7c. 

After the allocation of message space (in these examples four bits) to the operation code, 
16 bits remain. Since IP addresses have 32 bits and MAC addresses 48 bits, these will 
need respectively two and three Next Pages for transmission. Thus Figure 6 shows two 
Next Page exchanges and Figures 7a to 7c show three such exchanges. 




Now, as described above, the transfer of the user-defined user codes within the OUI 
Tagged Next Page exchange is used to convey the actual MAC or IP Address information 
between the two PHYs on the point to point Unk. 

As muhiple OUI Tagged Next Page exchanges must occur to transfer the MAC/IP address 
information, and since the OUI Next Page message may also be used for other types of 
proprietary information exchange, further bits of the OUI Next Page message are reserved 
for identifying the type c)f proprietary exchange that is taking place. Figure 5 illustrates the 
assignment of the 20 bits of user defined information. The four most significant bits (OP3 
to OPo) are the operation code; the remaining 16 bits provide information specific to the 
Op-Code. Figure 8 illustrates the different Op-Code assignments to enable the exchange 
of IP or MAC addresses. 

There are two optimisations possible here. The first is to use a different assigned OUI per 
message type, an OUI for MAC address transfer and a different OUI for IP address 
transfer. This would enable a reduction in the number of Op-Code bits required. The 
second optimisation is that once the 16 possible Op-codes are used up a different OUI 
Tagged Next Page exchange OUI can be used to expand the possible Op-Codes further. 
While these two optimisations are possible for corporations that have several OUIs 
allocated to them over time this may not he an option for smaller companies as they may 
only ever have one OUI allocated to them. 

The actual exchange would occur as follows. When the Auto-Negotiation Base Page 
exchange is complete the Next Page exchange, if supported would commence. Assuming 
that the far end supported this feature a Next Page OUI Tagged exchange would 
commence and the four Next Pages would be transferred. Once it is identified that an OUI 
Tagged Next Page exchange has occurred the OUI supplied would have to be examined. If 
the OUI were a known OUI, then the Op-Code field would be examined. If the Op-Code 
indicated an IP/MAC address transfer then the IP/MAC address information can be 
extracted. This would provide part of the MAC/IP address. A second, and in the case of a 
MAC address a third, OUI Tagged Next Page exchange occurs, qualified as above, to 
provide the remainder of the MAC/EP address. 




In the case of an IP address which is 32 bits long, the first 16 bits will be supplied in one 
OUl Tagged Next Page exchange, the remaining 16 bits in a second OUI Tagged Next 
Page exchange (see Figure 6). In the case of a MAC address which is 48 bits long, the first 
16 bits will be supplied in one OUI Tagged Next Page exchange, the next 16 bits .in a 
second transfer and the remaining 16 bits in a third OUI Tagged Next Page exchange (see 
Figures 7a to 7c). In all cases the type of data transfer, IP or MAC address, is indicated by 
the Op-Code. 

i 

If Auto-Negotiation should complete without the exchange of the part of the MAC/IP 
Address being supplied, say for example only one of the OUI Tagged Next Page 
exchanges takes place, then an error should be posted and the MAC/IP Address cannot be 
considered received. 

The second approach is to define a new Next Page Message Code to transfer the address 
information directly. Both an IP and a MAC address tag code could be defined (the actual 
addition of a Next Page Message Code to the IEEE 802.3 Standard is controlled by the 
IEEE so the actual assignment of the new Next Page Message Code would have to pass 
through the normal IEEE process). 

The Internet Protocol (IP) tag code Next Page exchange (see Figure 9) would consist of 
four Next Page exchanges. The first next page would consist of the Message page 
containing the IP Tag Message Code (Mio to Mo) and, the following three messages would 
contain the actual 32 bit IP Address (I31 to lo). 

The MAC Address (MAC) tag code Next Page exchange (see Figure 10) would consist of 
6 Next Page exchanges. The first next page would consist of the Message page containing 
the MAC Tag Message Code, the following five messages would contain the actual 48 bit 
MAC Address (A47 to Ao). 

The payload of these new Next Page messages would only contain the IP or MAC 
Address information. Hence as the entire payload would be defined in a Standard any 



vendor would be able to read the IP/MAC address contained in these messages regardless 
of the vendor of the equipment at the far end of the link. This would allow multi-vendor 
interoperable implementations of this topology discovery. This is not possible v^ith the 
current OUI Tagged Next Page message Code as the OUI in the message has to be known 
before the used defined information can be read. 

In addition, in both cases these new types of Next Page exchange also provide an 
improvement in performance. Using the OUI Next Page exchange to do a MAC or IP 
address exchange takes two or three OUI Tagged Next Page exchanges respectively, a 
total transfer of ten Next Pages in the case of an IP address and fifteen Next Pages in the 
case of a MAC address. In the case of the new IP address Next Page exchange this is 
reduced to four pages, in the case of MAC address Next Page exchange, six pages. 

Figure 1 1 shows for the sake of completeness in simplified form part of a network device 
incorporation the invention. Fast Link Pulses (FLP) are received on an inward path 100 by 
a port 101 which was an associated physical layer device (PHY) including a state machine 

102 organised to perform auto-negotiation as described previously. In normal operation of 
the state machine values held in registers 103 will be transferred to a remote device by 
auto-negotiation. The format and timing of the Next Pages exchanges 105 is determined 
by Fast Link Pulses. In the present invention, the relevant identification information, e.g. 
the OUI, MAC address and IP address as the case may be is transferred under software 
control (which also may govern the state machine) to relevant registers within registers 

103 and incorporated as previously described in Next Page exchanges controlled by the 
stale machine. 



Claims 

1. A method of exchanging identifying information between two devices which are 
capable of auto-negotiation according to IEEE Standard 802.3, comprising transmitting a 
plurality of Next Page message code fields which include fields constituting address 
information and a code specifying the nature of the address information. 

2. A method according to claim 1 wherein. the address information comprises a media 
access control (MAC) address. 

3. A method according to claim 1 wherein the address information comprises a network 
(IP) address. 

4. A method according to any foregoing claim and further comprising retrieving said 
address information from memory, and storing said address information in registers under 
the control of a state machine which performs said auto-negotiation. 

5. A device for use in a packet-based communication system and including at least one 
port associated with a state machine for performing auto-negotiation including Next Page 
exchanges, said Next Page exchanges including fields constituting an address of said 
device and at least one code field indicating the nature of said address, and means for 
providing said address for incorporation in said Next Page exchanges. 
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